r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r=me when ci is green

hmm, would it be possible to instead filter the ReprOptions so that we don't end up with unsupported ones? It feels brittle to simply handle incorrect info by ignoring it, e.g. it adds an implicit assumption that repr(simd) is only ever used for structs, and if we were to idk, extend support to unions at some point (even if unlikely) this code would suddenly be incorrect

alternatively, accept all Adts, but then match on the kind and skip + span_delay_bug if it's not a struct

it adds an implicit assumption that repr(simd) is only ever used for structs

according to the rfc it seems (at least for me) that this is only for structs https://github.com/rust-lang/rfcs/blob/master/text/1199-simd-infrastructure.md#types

Yes, but is this a guarantee that we'll never extend it to unions? My point is not that the code is wrong, it's that this code adds an implicit dependency which may result in bugs in the future.

Most bugs in large projects happen by:

• somebody writes code which has an unchecked assumption which holds right now
• somebody else modifies another part of the project, causing this assumption to no longer hold, resulting in a bug in entirely untouched code

This implies that a good way to avoid bugs in large projects it to avoid unchecked assumptions. It's why exhaustive matches are so powerful. It's also why we do stuff like

@lcnr
I updated the code in commit:
https://github.com/rust-lang/rust/compare/995c11894fdabe1c630694254de756f82389c6cf..112d833ea5c72f89078069ffc5d10da5b1adf2ca

I'm thinking do we need to delay_as_bug, since if we already returned Err(NonAsmTypeReason::Invalid(ty)), there will always an error reported error[E0084]: unsupported representation for ...

Ok, span_delay_bug seems checking the whether there is already an error before this point.